Businesses increasingly rely on business processes to accomplish various tasks within the organization. The business software that is used to implement the business processes becomes critical to the organization. Some software (e.g., SAP business software of SAP AG of Walldorf, Germany) allows customization and modification of the business process applications. Changes to the business processes may be made frequently (e.g., weekly or even daily) in some organizations. Prior to implementing a change in the business process software, the organization would ideally verify/validate the change to ensure the change accomplishes what is desired, and does so correctly without interruption to the normal flow of the organization. However, current methods of verification of the business process changes are expensive, time-consuming, and often require tradeoffs between reliability and cost and/or time.
Currently, business software is tested in one of two ways: manually, or via record and playback/scripting. Manual testing suffers from being very time consuming and having a small scope of possible tests. The risk that an error will “make its way through” the testing is relatively high. The inefficiency and cost aspects to manual testing makes manual testing a generally unacceptable procedure. Automated tests are generally considered to improve quality, but generating and maintaining test content is traditionally time consuming and expensive.
Record and playback testing traditionally involves recording an entire sequence of activities that a particular participant in the business process would perform. However, conventional record and playback requires that the test setup be an exact system duplicate of the recording. Variations between the systems frequently fail the testing. Additionally, the testing system must be extremely stable, given that changes to the system will fail the recording. Even in systems where the test does not fail for minor system changes, there is generally a limited access for test systems to business process content. While some traditional systems may not fail the test based on the changes, there is no ability to alter the test content based on changes. Furthermore, program scripting has a significant drawback in that specific tests must traditionally be written and adapted manually for every change. All current scripting tools have proprietary components that require specialists in the tool to implement. The cost of maintenance can become significant and possibly prohibitive. Thus, record and playback/scripting requires controlled conditions that are very difficult to produce, and difficult to duplicate. The complexity increases the cost of the procedure and does not guarantee the desired outcome.
Besides direct changes to a business process, a system may be affected by system maintenance. System maintenance is generally performed via a Transport Order that may include software changes (e.g., changes to technical objects such as code, user interfaces, etc.) as well as customizing and master data changes (e.g., table entries for configuration changes and master data tables). Such changes can cause the test case to fail even though the business process executed via a transaction of the enterprise software will still perform correctly. That is, the changes may cause changes that destroy the automated test case, even though the execution in the non-test system would perform correctly.